Voice over Internet Protocol (VoIP) has seen a rise in popularity in recent times and has become more than just a telephony application. For instance, several highly popular applications have come into existence like Skype™, Google Talk™, and MSN Messenger™. All of these applications combine voice, instant messaging (IM), and other modes of communication into unified clients and greatly enhance the user experience. Previously, these means to communicate were islands—largely isolated from each other. However, engineers visited them and found large areas of community between these different modes of communication, resulting in integrated clients that have changed the way in which communication and business is conducted.
For integrated communication applications, such as those described above, server support needs to be provided. An examination of the structure of such communications applications indicates that there are two parts to the application: the signaling part and the media part. The signaling part is an event-oriented activity. Network endpoints exchange one-way messages through various servers and signal the establishment of a session. Interesting services can be built by placing fragments of code, or “event handlers,” in the signaling path at the server. Furthermore, service providers may speed up their innovation processes and quickly launch new services if they use a standards-based component model and container architecture.
One standards-based application execution framework is JAIN SLEE or JSLEE. JAIN is an acronym for “Java APIs for Intelligent Networks.” JAIN aims for an enabling set of Java APIs to develop and deploy service-driven network applications. SLEE is an acronym for “service logic execution environment.” Together, JAIN SLEE (or JSLEE) is an application execution framework analogous to the Java™ Enterprise Edition (JAVA EE) environment. However, in comparison to JAVA EE, JSLEE's design principles explicitly aim for a low latency (<100 ms) and high throughput (thousands of events per second) environment optimized for asynchronous event processing, including transaction handling, high reliability, a distributed component model, and a standardized framework. Appropriately, JSLEE was designed for a network signaling environment, which is ideal for a communications platform.
Another protocol developed for signaling is Session Initiation Protocol (SIP). This important signaling protocol for the telecommunications industry is rapidly moving to next-generation applications. Java™ is an excellent platform for SIP development, especially on the server side. Similar to JSLEE, SIP servlets are a container-based specification. SIP servlets were designed to simplify SIP development by building container functionality on top of a SIP stack for programming convenience. SIP servlets integrate a SIP stack into the container to talk to the SIP network, which can be viewed as a library built upon a SIP stack hiding complexity from the application developer. In addition, SIP servlets are built upon the servlet concept, with the service logic coded in the SIP servlet, for a common programmatic feel.
JSLEE and SIP Servlets each address unique requirements for communications applications that are not addressed by the execution environment of JAVA EE. Currently, integration of JSLEE and SIP Servlets in a single Java™ Virtual Machine has been accomplished. However, a problem with the present integration of JSLEE and SIP Servlets is the complexity required to integrate the two specifications. In order for a SIP Servlet application to communicate with a JSLEE container, an additional layer, such as an EJB (Enterprise JavaBean) layer, is added to the SIP Servlet application to enable this communication. The addition of this layer means that the SIP Servlet application now must be deployed on a JAVA EE-compliant application server, rather than just a SIP Servlet-compliant server, which adds further complexity. In addition, with the current JSLEE API, there is no way for the SIP Servlet application to get a result back from the JSLEE container in a simple manner, as the present communication mechanism is an asynchronous or “fire and forget” mechanism.
As a result, a way to remove the additional layer of complexity in the interoperable JSLEE/SIP Servlets applications, as well as for SIP Servlet applications to fire events into JSLEE and control the return of that result, would be beneficial.